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[57] ABSTRACT 

The present invention includes a method and apparatus for 
distributing music to local, digital, electronic jukeboxes. In 
particular, a complete menuing system is stored in a central 
storage location. A portion of the complete menu is stored 
locally at the jukebox, depending on user demand. A juke- 
box selectively requests the transmission of songs from the 
central storage location using a variety of communication 
means based upon usage data with respect to songs and the 
menu. The request can be initiated by the jukebox and can 
occur automatically based on statistics compiled by the 
jukebox representing user demand. The central storage loca- 
tion processes the requests and schedules individual requests 
from each jukebox to coordinate transmission of music to 
multiple locations simultaneously. In addition, the central 
storage location periodically updates the local jukeboxes 
with a list of new releases, during which time the jukebox 
can also download the music. A portion of the complete 
menu is stored locally at the jukebox, depending on user 
demand. The jukebox also includes secure hardware used to 
decrypt and encrypt music and monetary certificates, to 
prevent improper use or copying of music. 

29 Claims, 15 Drawing Sheets 
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SYSTEM FOR SELECTIVELY 
DISTRIBUTING MUSIC TO A PLURALITY 
OF JUKEBOXES 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a music distribution 
system for jukeboxes. More specifically, it relates to a 
system in which a jukebox selectively requests transmission 
of specific songs from a centralized storage location based 
upon usage information, and a system which coordinates 
transmission to optimize channel bandwidth. 

2. Discussion of the Related Art 

Conventional jukeboxes play music from records or com- 
pact discs containing several songs. The records or disks are 
stored locally at the jukebox and are physically selected and 
played with these jukeboxes. The user views a display listing 
song selections contained in each record or disk. The user 
then selects a song to be played by depositing money into the 
jukebox and pushing keys which represent the desired song. 
A record or disc changer in the jukebox selects the appro- 
priate record or disc and transfers it to the player, which can 
take as much as 30 seconds. 

There are many deficiencies in conventional jukeboxes. 
The most significant problem relates to music selection. The 
users are limited to the songs on the records or compact discs 
which are physically present in the jukebox. However, much 
of the music on these records or discs may be unused. This 
is because less popular songs are often included on the 
record or disc with more popular songs. Jukebox records 
typically have two songs, one on each side. Compact discs 
may have many songs. Generally, only a couple songs on a 
disc are popular and played often. The remaining songs are 
merely part of the disc and are not played. Estimates indicate 
that 80% of songs in a jukebox may be unused. This wastes 
space in the jukebox which could have additional popular 
songs. Also, it is not easy to customize song selection for 
specific clientele at a location. Different establishments have 
clientele which often desire different types of music, or 
particular songs. There is no easy mechanism to determine 
the tastes of the users at a specific location. Therefore, the 
jukebox owner will use general popularity information to 
select songs. Alternatively, certain studies, either formally 
by researchers or informally through the establishment 
operator, will be used to select songs. Such studies also have 
deficiencies due to sampling problems. 

After music is selected, updating the music is time con- 
suming and expensive. The records or compact discs must 
be manually updated by replacing the records or disks. Each 
copy of the record or disc must be purchased and then 
installed in the jukebox. The title list also must be updated 
manually when discs are changed. 

Costs of installing and maintaining a jukebox can be 
extremely high. A jukebox can hold as many as 100 discs or 
records. Installation of the jukebox requires purchase of a 
complete set of records or discs. Additional purchases must 
be made in order to change the music. Also, since a jukebox 
includes many moving parts, breakdowns are common. 
Breakdowns often occur with the money reception portions 
or record/disc movement portion. Maintaining the jukebox 
requires visits from specialized technicians. Since the cost of 
playing a song is typically low, a jukebox is too expensive 
for an establishment in which songs are not often played. 

Therefore, a need exists for a jukebox which permits 
simple customization of song selection for specific loca- 



19,945 
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tions. A need exists for a jukebox system which eliminates 
manual selection and changing of songs. A need exists for a 
system which reduces the costs of operating a jukebox. 
In personal music listening, a tape, record or disc is played 

5 on a simple system. The possible songs are limited by the 
songs owned by the user. It is expensive to have a large 
music library, since each song must be purchased. Also, song 
selection can be quite time consuming with a large library, 
since the songs must be selected manually. The costs of a 

1Q jukebox prevent the user from using a jukebox as a personal 
music playing device. Additionally, if a person rents a 
jukebox, such as for a party, songs cannot be consecutively 
played. Rather, a delay is required between songs in order to 
change discs, which is typically between 8 and 30 seconds. 
Therefore, a need exists for a jukebox system which is 

15 inexpensive and can operate as a personal music player. A 
need also exists for a system which can play selections 
consecutively, and can include transition effects, such as 
fades. 

Some of the difficulties of conventional jukeboxes have 

20 been overcome by different variations of jukebox type 
designs. Generally, these systems are one of three types: 
on-demand streaming, near on-demand streaming, and 
downloading. In an on-demand streaming system, the user 
selects a specific song from a central or general library. The 

25 song is then immediately performed. On-demand streaming 
requires a high speed data channel, at least 128 to 256 kbps, 
between the server and the jukebox. Accommodating this for 
more than a local area would be prohibitively expensive. 
Such a system also requires an extremely high speed 

3 q modem, which is also expensive. 

Near on-demand streaming uses a variety of channels to 
transfer songs to a location for performance. The user can 
then select one of the multiple songs available on the 
channels, similarly to selecting a television or radio channel. 

35 In order to have the same replay possibilities as a jukebox, 
each song would have to be replayed approximately six 
times simultaneously. As with on-demand systems, the nec- 
essary bandwidth for real time transfer of music far exceeds 
today's technologies. 

40 In a download system, music is loaded a jukebox from a 
central location. The music is stored at the local location for 
future playing. A computer jukebox is an example of such a 
system. In a computer jukebox, the songs are digitally stored 
in a memory. For example, in U.S. Pat. No, 5,355,302 to 

45 Martin et al., new recordings are downloaded into the 
memory of each computer jukebox. Old recordings are 
erased from the memory to create space for the new songs. 
The jukebox monitors and stores information regarding the 
number of times each song has been played. The information 

50 is collected at a central location which uses this information 
to calculate royalty payments and to determine which songs 
are less popular and need to be replaced in the jukebox. The 
jukeboxes are managed remotely by a central management 
system using modems and public telephone lines or radio 

55 frequency transceivers and antennas. The central manage- 
ment location also contains a master catalog containing 
information about each song record it stores. The central 
management system monitors the jukebox, determines avail- 
able memory space in the jukebox and transmits the new 

60 songs and catalog information to update the jukebox. The 
computer jukebox stores songs and graphics locally with 
information about the songs. The jukebox can initiate com- 
munications with the central management system at prede- 
termined times or if the jukebox determines that an event has 

65 occurred that the management system should be aware of. 
In known computer jukebox systems, the central manage- 
ment system determines which songs need to be replaced 
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and which jukeboxes need to be updated by using new song avoid credit or debit falsifications. Several secure payment 
request data entered by customers to aid in determining mechanisms such as smart card, debit card, credit cards, etc. 
whether new song data should be downloaded to the juke- have been used. These mechanisms may provide a satisfac- 
box. The jukebox contains a classification hierarchy which tory security as long as the connections between the pay- 
allows the user to find a song of interest. However, existing 5 men t mechanism and the electronic control can not be 
systems do not include mechanisms for allowing the user to accessed by hackers or the software that controls the pay- 
select songs by classes of music types and do not provide ment mechanism cannot be modified, 
information at the local jukebox relating to song availability Hq for jukcboxes> the jukeboxes operators must 
at the central storage location. In addition, automatic mecha- haye access {Q ^ connections ^cause th need t0 service 
msms are not used to update songs based on jiser selections. 10 ^ machioes . ^ connections can be cut and payment 
Therefore, a need exists for a system which can automati- mechanisms ^ be emulated there5y fooling the electronic 
cally update songs based upon user preferences. cQQtxol Fmm ^ Qther ^ ^ toftwm ^ the 

In existing systems, songs are transferred from a central payme nt mechanism can be easily modified and fooled. In 

location to the local jukeboxes through a variety of media, mis way> hackefS avokJ paying me fees 

including satellite broadcasts, RF transmissions, telephone 35 need ^ {Q ^ a mQre ^ 

line transmissions and physical transfers 01 disks. Songs are , . . 4 . .„ * u 

f 11 . u - 1 u th, 1 mechanism that is still secure even if the payment mecha- 

generally transferred mdividually to each jukebox. The large . - 4 „. , 4 . . . 4 , c * A 

* * j **u a 1 j* * a\ u nism or software controuing it, is violated or fooled, 

files associated with downloadmg music files can be pro- & ' 

hibitively expensive, inefficient and time consuming. The SUMMARY OF THE INVENTION 

average size of a compressed song is on the order of 50 2 o 

megabytes. The cost to transfer the large files including The deficiencies of existing jukebox systems are substan- 

songs, can be prohibitive for a computerized jukebox using tially overcome by a jukebox system according to the 

a central music storage location. In order to compete with present invention in which individual songs are digitally 

traditional jukeboxes, the cost of music distribution must be stored. Music can be transferred fmm a central storage 

similar to that for purchase of new compact disks. 2 5 lo cation to the jukeb ox, to update the music witho ut a 

Additionally, the cost for the equipment to provide the physical replacement. A music Hierarchy system exists in the 

communication of the songs to the jukebox can be high. jukebox for determining c ustomer preference s in order to vA^£a. p^K>mZ<. 

Transferring songs over a telephone line using modems is automate music selection during updatin g. Also, a unique 1 ] 1 Q 

expensive, particularly if a long distance telephone connec- distribution system is used between the central location and ^^^&L§^\ 

tion is necessary between the jukebox and the central 30 the jukebox which improves on bandwidth utilization for I 

location. Although high speed modems are fairly transmission. \*rt.U 

inexpensive, in many locations, the telephone lines may not Accordingly, it is an object of the present invention to 

be sufficiently clear of noise such that the high speeds can be provide a jukebox system which uses a statistic replacement 

achieved. Higher bandwidth or speed telephone lines may algorithm working with different memory hierarchies, a 

not generally be available in many locations, and generally 35 scheduling algorithm, and conventional means of commu- 

cost more. ISDN communications have even higher speeds, nication with addressable and broadcasting capabilities, 

but are more expensive both for the telephone fine and for R ^ a Qbject of ^ t to ovide 

the equipment. Other types ot high speed modems, such as n . - ^ ^ 

music on demand and to v 

ADSL modems, also are significantly more expensive and > e aU ^ > reque sting music based on local 

connection* sare not widely available Satellite receiver costs 40 ^ ^ a[ deferred ^ ^ dekmcM results in \ 

is also high, both for the equipment and for he ongoing moK effid an(J >( a lower ^ ^ b 

service. Songs may also be transferred through the Internet, fining te from mul £ le locations for , si le 

but significant delays are possible The computer jukebox n £ music t0 the multi le jukeboxes simu i ta . 

still needs to be connected to the Internet through some type . 

of modem, although a long distance call may not be neces- 45 

sary. Therefore, a need exists for a more efficient transmis- . 11 15 a ***** ob J<f of ^ P resent mention to have a 

sion system. In order to compete with traditional jukeboxes, J^ 0 * programmable with different payment methods to k^J- 

the music distribution system must include a low cost for allow advanced payments and to allow automatic access by I J 

both the communication lines and for the communication ih& i^box to the central storage system. 

equipment. Also, as the size of the system grows, significant 50 It is a further object of the present invention_to store a 

increases in the cost of distribution equipment must be kept port ion of a hierarchial menu at a l ocal jukeb ox location and /7 +- 

at a minimum. t0 retrieve additional portions ofthe menu based upon local VsLtH ^ f\ 

Also, computer jukeboxes typically have a closed user accesse s. £oC« t ^' r 

architecture, i.e., the jukebox is associated with a specific The present invention also allows songs to be placed on 

music distributor and distribution system. This creates a 55 the local jukebox based upon user inquiries into various \ a 0a&& 

large dependency of the jukebox on the distribution system. areas relating to availability. The local jukebox automati- J iL^ pJ^ 

If the distributor ceases to exist, the music in the jukebox cally determines music to be retrieved at certain locations / tW' ^ 

may not be replaceable. Similarly, spare parts for repair may and selectively downloads music based upon actual user / <vVu^ 

cease to exist. Therefore, a need exists for an open archi- preferences at that location. ^O^^q 

tecture for a distribution system. 60 It is another aspect ofthe invention to create a system of ^^JJ 

Finally, a system of computer jukeboxes must be secure. music which has a low cost, both for equipment and service, 

Since songs are digitally stored in a modifiable memory for communicating songs to the jukebox and information to 1 

device, the songs can be copied to other devices. Also, the central location. According to this aspect of the / 

unauthorized songs may be loaded onto a jukebox. The invention, one of the jukeboxes, designated a master, can ' 

music distribution system must provide a mechanism for 65 operate as a regional service center. Music is communicated 

security of the songs to ensure a fee is paid for the copying from the central storage location to the regional service 

and distribution of the music. The payment mechanism must center. Music may be stored at the regional service center or 
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further transmitted to other jukeboxes. The subsequent Electronic Titles (VET). A VET is digitally encoded into a 

transmission from the regional service center to the slave secure digital envelope to be used for mail distribution or 

jukeboxes can be over local telephone lines at lower speeds electronic transmission or storage and can only be opened by 

with reduced costs. Similarly, the individual jukeboxes can authorized users. The VET envelope contains diverse object 

communicate information directly to the regional service 5 t v P<* with relational links, and packaging and accounting 

center information. VETs can be sold, purchased, stored, rented, 

r , - , . . . , . distributed, executed, reproduced, produced or inter- 

It is another aspect of the invenbon to provide a music cfa d Execution of ^ object t in a ygj results m 

distribution system which is compatible with the use of human tioQ of te hi ^ ^ ^ 

compact disks already owned by a jukebox operator The dimens £ nal etc ^ ^ ^ form me st 

computenzed jukebox can have an interface to connect with » mechanism for J a jukebQX Each ^ s[ored „ a 

commercial compact disk changers. Album covers and song ^ ^ wbich can ^ be executed demfmd 

names can be entered or scanned into the memory in the fr ^ ^ ^ Reproduc(ion of an object type in a VET 

jukebox^ If the user selecte one of the albums or songs on ^ rodud ^ object t m a media ^ ^ 

one of the compact disks the jukebox communicates to the ^ ^ Dis{ . (DVD) c , Djsc (CD) 

CD changer to select and play the appropriate song. » fc » prindng> prin ,£ g( etc . Thus, it 

It is another aspect of the invention to provide a secure jg ako poss ible to reproduce a song in another format so that 

environment for the transfer of music and other sensitive , ne customer can obtain an actual copy, and the jukebox can 

information (such as monetary certificates) for purchasing function as a retail distribution center. Royalty payments for 

songs or paying for services from the central location to each , ne transmission of copies can be ensured through use of the 

of the computer jukeboxes. The system includes secure payment mechanism discussed below, 
hardware in each of the jukeboxes which is used to encrypt mG 1 mustrates a music distribution system using VETs 

and decipher the music and other sensitive information (such acc0 rding to an embodiment of the present invention, 

as monetary certificates) for purchasing songs or paying for mc ^ ag access methods bet ween a jukebox and a central 

services provided to that jukebox. The music is stored in an st location FIG 1 coaiiins a yiP architecture in a . (K , / 

encrypted format which prevents copying to other locations, clien ^ server environment. Three main elements comprise CA i>/ 

including other jukeboxes within the system. The secure , he VIP) including the intelligent Terminal (IT) IT1-IT9, the 

hardware is used to ensure the authenticity of distributed Operation Service Centers (OSC) Rl, R2, Gl and the 

music and proper payment for the music. Communication Means (CM) CM1-CM9. Even though a 

BRIEF DESCRIPTIONS OF THE DRAWINGS 30 single distribution systeri .is nlustrated, multiple retribution 

systems may be used for distributing music to any of the ITs. 

FIG. 1 is a schematic illustration of a music distribution For example, as illustrated in FIG. 1, IT4 can receive music 

system according to an embodiment of the present inven- through either Rl (a primary distribution channel) or R2 (a 

tion. secondary distribution channel). Similarly, each IT may be 

FIG. 2, comprising FIGS. 2a-2 Cj is a schematic illustra- 35 connected to more than one independent network. Thus, 

tion of local music structure including a hierarchy of classes e . ach 17 can °P erate m ™ open architecture which is not 

of music limited to a single distributor. The IT can operate like a 

_^ ' , c u- c computer in that it can include instructions for connecting to 

FIG 3 is a schema ic illustration of a queue chain for m ^ distributkm networks A sin ^ e network fc iUus . 

requested music in a statically assigned channel server. ^ M ^ mQ x ^ ^ * 

FIG. 4 is a schematic illustration of a queue chain for fa one embodiment of the present inve ntion, the IT is a 

requested music m a dynamically assigned channel server. Personal Jukebox (pj) that can be capabk of supplying 

FIG. 5 is a schematic illustration of a queue chain for music execution on demand 95% of the time at no cost, 

requested music in a delay lock out channel server. Personal Jukebox does not limit the devices to in-home 

FIGS. 6a and 6b illustrate the process for initialization of 45 locations. Rather, it refers to the capability to select songs 

the secure hardware in a security mechanism of the present according personal tastes and desires of the customers at a 

invention. specific location. However, the distribution system of the 

FIGS, la, lb, and 7c illustrate the process for distribution present invention can be used to provide music through a PJ 

of music using the security mechanism of the present for individuals in-home. The high capability of the PJ to 

invention 50 execute music on demand is achieved by sensing the music 

FIGS. 8a, 8b, and 8c illustrate the process for distribution d ^ and ^ <*» from end ««■■ 88 di f u * sed below "The 

of monetary certificates in the security mechanism of the ™ -^f f ^ w * u 

present invention physically place VETs m a storage platforms closer to the 

« .« ^ , < end usere which wiU likely request such VETs. The Regional 

illustrates a block diagram of a second embodi- 55 Seryers R1 R2 m me osc use the local demand ^ 

ment of the music distribution system according to the information to determine local popularity demand, while the 

present invention. Global Server Gl uses the information to determine regional 

DETAILED DESCRIPTION popularity demand. Each PJ uses individual demand sensing 

to determine local storage of VETs. 

The present invention relates to a jukebox with digitally 6 o The PJ platform (any of IT1-IT9) contains a CPU hard- 
stored music, and a music distribution system for replacing ware box, a massive storage system, and a real time oper- 
music in the jukebox. It includes an apparatus and method ating system and drivers for the hardware devices. The CPU 
for requesting certain music stored at a central storage hardware box is based on PC-like hardware or set-up-box 
location and transmitting it to local jukeboxes. type hardware. The massive storage system is large enough 

The present invention more particularly relates to a Vir- 65 to store more than 200 compressed songs, as VETs, with 

tual Inventories with Perpetual Reproduction and Execution associated data types (text and graphic images), or generally 

of Electronic Titles (VIP) architecture for managing Virtual has about 1 Gigabyte storage capacity. The massive storage 
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system is scalable to the user's needs. Since songs can be extremely high speed bandwidth. This method is actively 

individually selected for inclusion (or deletion) from the being developed in the US by the increase in fiber optic 

storage system of the PJ, only desired songs need to be communications. 

stored. No storage is wasted on songs which are not desired. IT7 X1SCS me terrestr j a i y wireless technologies Multipoint 

The Global Distribution Platform Gl in FIG. 1 consists of 5 Multichannel Distribution Service (MMDS) or Local Mul- 

a LAN connected to a WAN. This Global Operational tipoint Distribution Service (LMDS) for access to the OSC. 

Service Center Gl is comprised of a master server, hierar- MMDS is unidirectional with a high bandwidth. LMDS 

chical storage subsystem a communication server a con- ^ bi . directioaal based on cellular-like technology, 

nection equipment to a public or private network, and a VET T „ , „. . .... 

factorv uses only a satellite receiver and is not interactive. 

Regional OSCs Rl, R2 are similar to the Global OSC Gl, 10 ^s are broadcasted continuously and the ITs automati- 

except that they do not require a VET factory. Regional ^ s ^ lect what they want to download based upon local 

OSCs Rl, R2 are geographically closer to the ITs that they demand statistics as discussed below. ITs are charged a 

are serving. Thus, they can provide a faster, and generally P eriodic fee or are charged for the number of VETs that are 

less expensive, source for any given VET. As noted above, down loaded. The OSCs have the ability to disable/enable 

the demand information from each of the PJs corresponding 15 the IT downloading (reproduction) and execution capabili- 

to a Regional OSC can be used to determine specific VETs ties of the IT. 

to maintain at the Regional OSC. Regional OSCs, such as IT9 uses a portable computer to capture transaction and 

Rl, R2, can operate as alternate nodes in the VIP network statistical information from the IT, and downloads contents 

and a OSC replacement for other regions so that if a node in required by the IT. The connection between the IT and the 

the VIP network fails, alternative routes and alternative 20 OSC is through a port or LAN. 

Regional or Global OSCs can be accessed. While a single A communication server or access server performs the 

level of OSC is illustrated between the Global OSC and the interfacing functions of network protocol translation, speed 

PJs, multiple levels may be used. The demand information matching, buffering, and network packet routing between 

is used at each level to maintain the most popular songs for tne IXs and 0SCs When satellite delivery to the ITs 

the lower levels. tne ne t W ork carrier is connected to the OSC by means of a 

The OSC provides operation services to the ITs. In FIG. high speed Tl or El link (or other high speed link) from the 

1, different options for the ITs to access the OSCs are shown communications server to the satellite up-link, where data 

CM1-CM9. There is a high volume, high speed distribution win be sent to the satellite for delivery to the geographically 

of VETs from the OSCs to the ITs. In addition, there is a low ^ distributed ITs. The communication server and the OSC are 

volume, low speed exchange of information from the ITs to internally connected to a Master server through a network 

the OSCs. The information exchanged includes the IT hub which performs the interconnection of all network 

sending a VET request to an OSC, an IT accessing statistical devices to guarantee a high network throughput speed, 

information at the OSC, an OSC accessing sales information VET factory in the Global OSC Gl produces VET 

from an IT, and an OSC making a remote control diagnostic, enve lopes which are transferred throughout the system. The 

etc. If a Regional OSC fails, an IT can connect to another factory has one or more multimedia workstations with 

Regional OSC, or to the Global OSC for services. editing and aum0 ring capabilities, temporary storage, con- 

IT1 in FIG. 1, uses an asynchronous analog telephone line tent cap ture units and an internal connection to the OSC 

for the exchange of information. IT1 sends a request for a network hub. The workstation is connected to the LAN and 

VET to the Regional OSC to reduce the cost of the telephone ^ WAN through the network hub so that the workstation can 

call. The Regional OSC Rl then forwards the request to the access me master server and the external WAN devices. The 

Global OSC Gl, which in turn up-links the requested VET contents of the VET can include text such as an album name, 

to the satellite. The satellite then transmits the requested name> aul hor, producer, date, serial number, royalty 

VET to the IT1 satellite receiver. In this embodiment, only owner, etc., an image such as an album cover, or audio such 

a receiver, antenna, down converter and a phone line are 45 as tne song or digital file. The workstation creates the VET 

needed locally. and sends it to the Master Server through the Network Hub. 

IT2 uses an integrated digital switched network for the The Master Server in turn updates the VET data base. The 

exchange of information and VET distribution. This network workstation has ports to connect to capture devices, such as 

requires a modem and is currently becoming standardized CD players to capture songs. The capture unit converts a title 

among service providers. 50 m t 0 a signal. 

IT3 uses removable discs to store all information related \ Q the present invention, a VET envelope is distributed as 

to accounting, sales, user VET requests, etc. The disc is a single unit. The envelope contains a group of VETs of the 

mailed to the contracted OSC where the information is same or different data types liked together. Normally, the 

loaded into databases to process the information. The OSC vets in an envelope will have a title relationship. For 

then generates a custom made disc with the VET requests for 55 example, an envelope can be created from an album so that 

the specified IT user. Alternatively, the OSC may generate a the envelope contains five songs from the album. The 

generally programmed disc with common distributions, such envelope would contain 5 compressed and encrypted audio 

as for new songs. titles, 5 uncompressed non-encrypted song titles, each linked 

IT4 uses a cable modem to exchange information and to its respective audio title, one uncompressed album title 
request VETs. Currently, there is no uniformity among cable 60 liked to each of the song titles and one compressed non- 
operators which makes this method of accessing the OSC encrypted cover page linked to the album title, 
difficult. Also, some cable operators do not have bidirec- The access method between a PJ and a central storage 
tional data transmission capabilities. location as shown in FIG. 1 includes the following steps. 

ITS uses an asymmetric digital subscriber line to The OSC periodically broadcasts to all locations a list of 

exchange information and request VETs. 65 new songs available for distribution. The Personal Jukebox 

IT6 uses switched digital video or a hybrid-fiber coaxial (IT1-IT9) downloads the list of new songs. The PJ deter- 

cable modem to access the OSC, which allows for an mines the users' demand by capturing the users' require- 
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ments and processes the demands statistically. The PJ then 
determines which new titles are convenient to download. 
Previous to the attempt to download, the PJ would have been 
loaded with credits through a bank payment, bank deposit or 
a PJ fund collection mechanism, such as coins, bills, smart 
cards, etc. Once the credits are deposited, th e PJ is auto - 
enabled or not disabled by the OSC satellite transmission to 
download a number of song titles. As a title is downloaded, 
the number of credits is decreased. Th e PJ downloads only 

titles that it has selected, as long as credits remain. Each of * jj.^ i c 

the jukeboxes locally stores a portion of the music available 10 ?P™ te iceboxes. Each request for additional portions of 



When a portion of the hierarchy is retrieved, it will not 
necessarily retrieve everything under it. Rather, it will 
retrieve one level and portions of lower levels. Additionally, 
portions of the hierarchy and songs which are not accessed 
as often are deleted in order to make space for new portions 
and songs. Thus, the jukebox is automatically 
songs of interest to the clientele for that 

The system also optimizes the channel bandwidth for 
transmission of information from the central location to the 



ce for new portions 

ically updated w ith J ^fcxJU^ 

particular loc ation. | *^ jJL& 
inel bandwidth for ^A#KL 

ntral Innatinn tn the " 
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in the system and can play that music. Music not on the 
jukebox can be retrieved from a central storage location 
through any electronic transfer medium such as CM1-CM9 
shown in FIG. 1. Only musi c which has been e nabled 
throu gh the use of the credits can be re ceived, deciphered 
and played. When a PJ runs out of credits, songs are not 
enabled. Also, music which is copied from another source, 
such as another PJ, will not be enabled. Thus, improperly 
copied songs cannot be deciphered or played. Other security 
features are discussed below. 20 

FIG. 2, which comprises FIGS. 2a-2c, illustrates a local 
music structure for determining demand information and 
performing song selection. Such a structure is included at 
each level in the VIP based upon information from a lower 
level. The structure includes a hierarchy of classes of music 25 
with levels for music types (such as Latin) and sub-types 
(such as Samba, Salsa, Merengue), albums, and songs. Each 
jukebox includes only a portion of the hierarchy which 
would be locally accessible. The entire hierarchy would be 
located in the central location. Regional distribution 30 
locations, such as Rl, R2 in FIG. 1, may include all or a 
portion of the hierarchy. The portion of the hierarchy on the 
jukebox is then traversed in order to select songs that are 
locally available to be played. T he user selects a music typ e, 
then a sub-type, an album an d then a son g. Only songs for 35 
which VE'ls are stored can be locally accesse d. Even though 
a user selects an album, not all of the songs on the album 
may be stored or selected. Thus, the popular songs on an 
album are stored while less po^uJax_SQrigs are not. 

In order to determine ^user preferenc es^) the user can 40 
traverse the hierarchy to select types 15ftnusic or specific 
songs which are not currently available and which would be 
desirable. These songs can then be downloaded to the 
j ukebox from the ccntral (or regional) location. The jukebox 
^maintains stat istics^ egarding the number of times that a 45 
node in the Hierarch y is review ed b y a use r. If the node is 
reviewed a certain number ot times (eitner within a given 
time period or as a certain percentage of the total number of 
nodes visited), information which is below that node is 
retrieved from the central storage location. Thus, there may 50 
not be any songs locally from a type of music. However, as 
users access the hierarchy and select each type, i ts statisti cs 
i ncrease until lower port ions of the hierarch y should be 
ret rieve d. The number oFEits necessary in order to request 
additional portions of hierarchy or of certain songs from the 55 
central location can vary based upon the obj ectives fo r the 
jukebox. More rapid retrieval, such as direct<gjn jine acces s, 
would naturally be more expensive. Alternatively, the sys- 
tem can request that the new music or hierarchy be sent 
within a given time, such as two days. As discussed above, 60 
some songs may be periodically broadcast from the central 
location. The hierarchy may also be similarly broadcast. 
With this structure, when a jukebox determines that a song 
or portion of the hierarchy is to be retrieved, it monitors the 
broadcast until the song or portion of the hierarchy is 65 
broadcast. When detected, the jukebox will download the 
desired information from the broadcast. 



the hierarchy or for specific titles of songs includes a time 
for delivery. When information is requested so that times for 
delivery overlap, the information can be simultaneously 
transmitted to multiple jukeboxes. This is particularly rel- 
evant when the information is transmitted by satellite or 
through a computer network. It permits a broadcast trans- 
mission to multiple final locations. 

In one embodiment of the present invention, the Song/ 
Album Cover ratio is the number of productive songs in an 
album. The productive songs are classified in two types: 
those that generate 80% of the monthly sales and those that 
generate the remaining 20% of sales. Based on studies, the 
present invention uses 16% of the album songs in CD-based 
jukeboxes which generate the 80% of the monthly sales. 
Those songs are Top Performers. The Average Performers 
are the 11% of the album songs which generate the other 
20% of sales. The total number of productive songs is the 
combination of the Top Performers and the Average Per- 
formers. The OSC inventories are loaded with productive 
songs only, thereby eliminating 73% of the of the non- 
productive songs. The Top and Average Performers, 
Monthly Premiere songs and the index are periodically 
transmitted by the central storage location without any 
requests from the jukeboxes. 

During transmission, one bandwidth requirement is nec- 
essary for the transmission of the Top and Average Perform- 
ers and Monthly Premiere songs, which is a non interactive, 
update transmission which can be programmed to occur in 
programmable periods, such as twice a month. All local 
jukeboxes receive the non-interactive broadcast of the new 
titles. The titles can be actually downloaded by the juke- 
boxes during the broadcast time. A second bandwidth 
requirement is necessary for the interactive, update trans- 
mission when the jukeboxes request their VETs from the 
OSCs based on user demand. This often occurs when a 
jukebox is installed in a new location. Both the interactive 
and non-interactive modes can run simultaneously. 

This results in a Coincident Overlapping Concurrent 
Delivery (COCD) system to minimize the bandwidth 
requirements and the cost of transmission and to improve the 
availability of transmission of VETs. Different clients may 
request the same VET in an overlapping time. The more 
overlapping time that exists, the more chances there are that 
more clients will share the same VET delivery. Overlapping 
time is promoted by offering the lowest cost for the clients 
tolerating the longest transmission delay range. 

The COCD is comprised of a queuing system, 
distributors, channel servers, a COCD controller and a 
request conflict handler. A queue includes VET_Groups 

which represent one or more VET Transmission_ 

Requests. The queues have a concatenation pointer to move 
the VET_Groups that complete their wait time in the queue 
to another queue or to a Distributor. The Distributor sends 
the VET_Group to a Channel Server for transmission. 

In the COCD system, an IT, such as a Personal Jukebox, 
sends a VET„Transmission_Request when it requires a 
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VET to be transmitted. Queues, Groups and Requests have more precise wait time before transmission. This feature is 

unique instruction parameters. The class parameters include: particularly suitable for broadcast transmission systems, 

instructing the COCD system how long the VET should wait which require some type of deterministic transmission time, 

before transmission, indicating during what time frame the For example, with non-interactive satellite transmission (IT8 

transmission should occur, instructing the COCD system 5 in FIG. 1), the OSC must transmit the song names (the mdex 

about communication savings, and indicating when the hierarchy) of new songs which are available. The system 

queue becomes enabled for transmission, etc. The availabil- raa y delav . a ^ t™, such as one week, for each jukebox 

ity parameters include indicating to the COCD the worst t0 determme demand for each of the new songs before 

case delay window expected for a group in that queue. *™ J??* S ™ gS them ^ lves * Au u 

^ ' „ „ . . . , c 1 ^rt^rx m 1° FIGS. 3 and 4, queues 1 and 4 have been assigned a 

The COCD controller is a task which j^rfonns the COCD 10 channd fa Dislributor L ^ Qther queues ^ 

intelligence and operation. It creates VET_Groups, inserts nGS ^ 5 m concatenated t0 the Next__State or the next 

and moves them from queue to queue, updates the param- queue For examp i e) m F IG. 3, the output of queue 3 goes 

eters and arranges the scheduling. t0 me input of queue 2 an d the output of queue 2 goes to the 

The OSC will invoke the COCD upon receipt of the ITs mpu t of queue 1. Queue 1 occupies 66% of the time of the 

VET_Transmission_Request. The COCD determines 15 channel server, while queue 4 is using only 33% of the 

which VET_Groups are pending for transmission with the channel service's attention. 

same VET name and compatible instruction parameters. A ^ q Ueu ing system of the present invention allows for 

new group is created and inserted in the queue if the tne more efficient transfer of music to multiple locations, 

VET_Transmission_Request and the VET_Group do not saving both time and money. 

have the same class parameters. Otherwise, the VET_ 20 Th e Persona l Jukebox in the present invention may be for 

Transmission_Request is stacked in the group. If a shorter eithef commercia i or home use . For the home version, the 

delay time is requested, then the group is updated with the monitOTf communication equipment, funds collection units 

new request availability parameters and all of the stacked and the SQUad su5system ^ optional md can be added at 

requests are moved to a higher availability queue that wni since the home user may have a television as a monitor 

matches all the instruction parameters. If a shorter delay afld a home soand system cormected t0 the PJ . 

time is not requested, then the request is stacked in the piGS Mc ^ of a ^ m 

g^P-^f nsuresthatonlv one transmission wifioccurfor acc t0 an embodiraent of the present invention. The 

all the pending requests stacked and waiting in the same ^ {& ^ tQ , { { q{ 

group for the same VET transmission. ^ ^ m a pers0Qal ft ^ pfevents UQau . 

Hie COCD Distributor chooses VET_Groups from one thor ized storage or playing of music with the Personal 
or more enabled queues and distributes them to one or more Jukebox. It also prevents improper use of monetary certifi- 
channel servers. The Distributor balances the choosing and cates for purchasing song copies or other types of 
distributing as a function of the weight of the queue and the produc ts or services. In the security system of the present 
throughput of the channel server by implementing distribu- 35 mvention> tne songs ia ea ch jukebox are stored in an 
tion functions such as round robin, fixed priority, daisy encrypted format which prevents them from being trans- 
chain, etc. ferred to another jukebox or other storage medium. Music 

The channel server in the COCD receives the groups from which is transferred to the jukebox from one of the OSCs is 

the Distributor and performs the actual VET transmission. a iso encrypted. The decryption of the transferred music 

FIGS. 3, 4, and 5 illustrate an example of the COCD system 4Q requires sufficient monetary credits; otherwise, the VETs 

with several VET requests waiting. There are 6 different cannot be decrypted. Similarly, the coordination of the use 

queues configured in the COCD as shown. 0 f monetary credits must be controlled by the OSC to 

In FIG. 3, queues 1, 2, and 3 are concatenated and prevent unauthorized increases in credits, 

illustrate optimizing availability of statically assigned chan- Each PJ includes secure hardware, which, according to 

net servers. If, for example, a VET_Group X is the first in 45 one embodiment is located on the audio card. The secure 

a queue and the higher availability queues in the chain are hardware, implemented in a monolithic format, is used to 

empty, the Distributor will pull the VET_Group X for encrypt and decrypt information. Since the secure hardware 

transmission, causing the transmission to occur ahead of is monolithic, only the input and output data can be 

schedule. This feature is especially suitable for communi- accessed. All of the digital inputs and outputs to the secure 

cation services where the channel servers are statically 50 hardware are in an encrypted format which prevents unau- 

assigned (continuous) because the OSC is charged whether thorized copying of the VETs or monetary certificates or 

the channel is used or not. The COCD reschedules the VET another sensitive data. 

requests to distribute them to optimize the use of the channel secure hardware for each PJ is unique, and will 

server time. decrypt and encrypt data differently. Therefore, the secure 

In FIG. 4, queues 4 and 5 are concatenated and illustrate 55 hardware is not transferable between different jukeboxes, 

optimizing transmission costs of dynamically assigned However, if the secure hardware for a jukebox becomes 

channel servers. By delaying the transmission of requested damaged, it must be repaired in order to retrieve and decrypt 

VETs, there is a reduction in data transmission and a lower the VETs stored by that secure hardware. A set of public and 

transmission cost, especially when channel servers are private keys are used to encrypt and decrypt VETs in the 

dynamically assigned because the carriers charge according 60 secure hardware. The OSC can maintain a proper index to 

to the amount of data transmitted. keys which can be used to repair or replace defective or 

In FIG. 5, queue 6 is by itself and illustrates optimizing damaged secure hardware. Preferably, a maintenance person 

for delay lock out. In this embodiment, there may be a will need to access the data (after entry of passwords or other 

precise time specified for a particular group in a queue. appropriate safeguards) at the OSC to download the neces- 

These VETs are time dependent, and are therefore not 65 sary keys for correcting the secure hardware. The initializa- 

promoted to a higher availability queue and are not stacked tion process for the secure hardware is illustrated in FIGS, 

with or into other VET groups. This delay lock out allows a 6a and 6b. 
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As illustrated in FIG. 6a, an authorized center of the OSC FIG. 7c illustrates a process for inputting songs from 
generates an external IT (Intelligent Terminal or Juke Box) sources other than the OSC. The secure hardware is used to 
key, an external SH (secure hardware) key, and an external compress and encrypt a received song as a VET. The VET 
serial number for the secure hardware and corresponding IT is divided into blocks (step 232), each of which can be 
(step 101). This information is encrypted (step 103) using a 5 associated with a cost. The cost and VET data are multi- 
secret SH key (step 102) which is known exclusively at the plexed (step 235) and encrypted (step 238) using the VET 
OSC and the specific secure hardware. The encrypted key. The outputted VET envelope is then stored in the IT 
information, called an initialization envelope, is then deliv- hierarchical storage (step 240) for further processing, 
ered to the secure hardware of the IT The initialization FIGS. Sa-Sc illustrate the process for increasing mon- 
envelope can be transferred in different manners, including 10 eta ry credits for an IT. Monetary credits are increased by 
on physical disks, by modem, or through a broadcast to the transferring a monetary certificate to the IT from the OSC. 
specific IT. The secure hardware then decrypts the initial- The monetary certificate is encrypted to prevent unautho- 
ization envelope (step 106) to recover the external keys and rized modifications. At step 301, the certificate is created 
serial number. No other IT knows the Int. SH key (105 in with an amount and proper keys. The monetary certificate 
FIG. 6a) used to encrypt the initialization envelope, there- 15 (with or without a monetary amount) can also include a new 
fore the envelope can exclusively be decrypted by the IT for VET key to be used for later dated VET transfers. The 
which the envelope was generated. The secure hardware certificate is then encrypted using the internal IT key for the 
then determines whether the initialization was proper by IT to receive the credit (step 303). Of course, the transfer of 
comparing the external SH key with the internal SH key. If money to the OSC from the IT owner can be performed in 
the keys do no match, then the initialization envelope has 20 different manners, such as by satellite, keyboard, modem 
become corrupted (or is unauthorized) and the process and fax to transfer the monetary credits. The certificate is 
terminates (step 109). Alternatively, the IT can be disabled, then transferred to the IT through an appropriate transfer 
since an unauthorized modification was attempted. If the mechanism. Such mechanisms can include direct transmis- 
keys do match, then the internal IT key and internal serial sions or through transfer of appropriate codes to be entered 
number are updated with the new information from the OSC 25 on a keyboard. The internal IT key is used to decrypt the 
(steps 110, 113). If the secure hardware is being repaired or certificate (step 322). The certificate is then authenticated by 
replaced, the external IT key selected by the OSC will comparing the received external IT key to the internal IT key 
correspond to the internal IT key for the device where the (step 325) and comparing the received external serial num- 
secure hardware is located. Since the VETs are encrypted ber with the internal serial number (step 331). If there are 
and decrypted using the internal IT key, the repaired or 30 any differences, the certificate is judged to be invalid. When 
replaced secure hardware can decrypt and play the previ- a certificate is invalid, the transaction can be aborted, or, 
ously stored VETs. The serial numbers are used to control alternatively, the IT may be disabled (step 327). Serial 
monetary credits as discussed below. numbers are used to ensure that certificates are not 

The process for distributing VETs in connection with the counterfeited, duplicated or lost. Each certificate has a serial 

security system is illustrated in FIGS, la, lb, and 7c. A 35 number set by the OSC. The serial number in the IT 

compressed VET 201, including a corresponding cost, is corresponds to the last serial number sent to the IT. The 

encrypted (step 203) at the OSC using a VET key 202 to serial number is initialized in the secure hardware from the 

create a VET envelope. The VET key can be based upon OSC as discussed above. When each certificate is received, 

time to prevent a broken code from being used continuously. tne internal serial number is increased (step 331) by a 

The VET envelope is then transferred to the proper ITs, 40 predetermined amount. Typically, serial numbers may be 

where they are stored in the IT hierarchical storage. Since increased by one, but other amounts could be used for 

the VET envelopes are encrypted when stored they cannot further protection. If the certificate is determined to be 

be improperly copied by others. The VET envelopes can be authentic, then the internal monetary credits are increased by 

copied to other ITs or other storage devices, but a proper key tne amount of the credits in the certificate (step 333). 

is needed to decrypt them. The secure hardware is then used 45 The monetary certificates can also be used to transmit new 

to decrypt the VET envelopes. First, a proper VET key is VET keys. When a certificate is received, the VET key is 

selected (step 216) based upon the date of the VET envelope. compared to the internal VET key (step 335). If it is 

The VET key is used to decrypt the contents of the VET different, then a new key is being provided. The system then 

envelope (step 218). If the IT has sufficient monetary credits stores the VET key along with the date of the certificate. The 

(steps 207-209), then the decrypted VET is again encrypted, 50 new VET key is used for VETs received after the certificate 

this time with the internal IT key of the secure hardware and until the next VET key change is made. Since VETs may 

(step 224, FIG. lb). The encrypted VET is again stored in the be stored before being decrypted, the VET keys for various 

IT hierarchical storage. When a song is selected to be dates can be stored in a memory 334 of the secure hardware, 

played, the VET is retrieved from storage and decrypted The certificate can also be used to adjust the block cost for 

using the internal IT key (step 227) in the secure hardware. 55 creating VETs which are not from the OSC. The internal 

At steps 228-229, the VET is then decompressed, D/A block cost is set to the received external block cost (step 

converted, and output to the audio amplifier 230. Monetary 338). The internal block cost is used in the VET processing 

credits are used for decrypting VET envelopes. This ensures as discussed above. Once the certificate has been fully 

that payments are received for songs which are provided to processed, the processing ends. 

an IT. As noted above, the VET envelope includes a cost. 60 FIG. 9 illustrates a second embodiment of the music 

The IT includes an internal store 212 of the monetary credits distribution system according to the present invention. As in 

available. The cost of the VET to be decrypted is compared the first embodiment, this embodiment includes a global 

with the value in the internal store 212. If the internal credits music distribution platform 908 which is an operational 

are sufficient, then the amount in the internal store is reduced service center. The operational service center 908 can com- 

by the VET cost (step 209) and the decrypted VET is further 65 municate to jukeboxes using a variety of mechanisms. For 

processed, as discussed above. If the internal credits are not example, communications can be on telephone lines using a 

sufficient, then the decryption is terminated (step 210). modem 911, through removable storage media 907, 916, 
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such as diskettes, or through satellite 901 transmissions. 
With satellite transmissions, songs and other information 
can be transferred to a large number of jukeboxes 
simultaneously, reducing the total transfer cost per song. A 
stand alone/listen only jukebox 927 may be connected to a 5 
satellite receive 919 to only receive satellite transmissions. 
It may not have direct communications to the operational 
service center 908. Alternatively, a listen/talk jukebox 926 
may receive songs through the satellite receiver 918 and 
may transfer information through a telephone line modem 10 
917. Typically, this connection would be a long distance 
telephone connection, which would be expensive for trans- 
mitting songs, but could be used for transferring playing 
data, which has a much smaller volume. Removable storage 
media 916, such as a diskette, can be used for communi- 15 
eating with a stand alone mail jukebox 925. The songs and 
the playing data can be transferred by mailing diskettes from 
the operational service center to the jukebox location where 
they are loaded by an operator. 

The distribution costs for music and the collection costs 20 
for playing data can be further reduced by use of an operato r 
region 90 2. One of the jukeboxes in the operator region 902 
" fuiictiun s as a master jukebox 906. The master jukebox 906 
operates in a manner similar to the regional operating 
service centers Rl, R2 of the first embodiment of the 25 
invention illustrated in FIG. 1. In addition, the master 
jukebox 906 functions as a regular jukebox location. Thus, 
the master jukebox 906 can communicate with the opera- 
tional service center 908 through any of the distribution 
types, including telephone line modems 910, removable 30 
storage 907, or satellite reception 903. In addition, the 
master jukebox 906 is connected through telephone line 
modems 910, 913, 914, 915 to a plurality of slave jukeboxes 
922, 923, 924. Preferably, the slave jukeboxes 922, 923, 924 
are located within a local calling region of the master 35 
jukebox 906. In this manner, the songs can be distributed 
less expensively from the master jukebox to the slave 
jukeboxes. Alternatively, removable storage media 912 can 
be used for transferring songs to slave jukeboxes 920, 921. 
The communications between the slave jukeboxes and the 40 
master jukebox can also be two way. In this manner, the 
information about playing of songs, and the selections for 
new songs can be transferred back to the master jukebox. 
From there it can be transferred to the operational service 
center 908. Although FIG. 9 illustrates a single level 45 
between the operational service center 908 and the master 
jukebox 906, any number of regional operational service 
centers or other master jukeboxes can be used in a hierar- 
chical structure. Since each master jukebox will communi- 
cate with only a portion of the slave jukeboxes in the system, 50 
communications over telephone lines should be sufficient. A 
single phone line can provide 270 hours of communication 
per month. Assuming that the transfer of a song lasts 
approximately 20 minutes, a single phone line can distribute 
2160 songs per month. The master jukebox 906 could 55 
provide an average of six new songs per month to 360 slave 
jukeboxes. With this number of songs, each slave jukebox 
may be assigned certain time slots for accessing the master 
jukebox. When accessed, the slave jukebox can transfer the 
playing information to the master jukebox and download 60 
any necessary songs. 

FIG. 9 also illustrates use of the present invention in 
connection with current jukebox technologies. Many juke- 
box operators may already have a significant inventory of 
compact disks on which a large portion of the music is 65 
stored. As illustrated in FIG. 9, a jukebox 927 can have an 
interface for connecting to a CD changer 928. The existing 
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inventor of compact disks can be placed in the CD changer. 
In addition to selecting songs stored in the memory of the 
jukebox 927, the jukebox can be programmed to operate the 
CD changer through the interface. Thus, if a user desires to 
listen to a song which is located on an existing CD inside the 
CD changer, the jukebox will provide a signal to the CD 
changer to select and play the desired song. In order to 
operate with the CD changer, information about the CD's in 
the changer must be entered into the jukebox. A scanner 929 
can be connected to jukebox for scanning in album covers to 
be displayed during the selection process. A keyboard 930 
can be used for entering song information, as well as the 
specific location of the CD's in the changer. 

Having now described a few embodiments of the 
invention, it should be apparent to those skilled in the art that 
the foregoing is merely illustrative and not limiting, having 
been presented by way of example only. Numerous modi- 
fications and other embodiments are within the scope of one 
of ordinary skill in the art and are contemplated as falling 
within the scope of the invention as defined by the appended 
claims. 

What is claimed is: 

1. A music distribution system for local digital electronic 
jukeboxes comprising: 

a central storage location including available songs, 
graphics, and titles; 

a menuing system, said menuing system includes storing 
a portion of a menu at a local jukebox location, wherein 
the local jukebox location is separate from the central 
storage location, and storing a complete menu at said 
central storage location; 

a communication means between said central storage 
location and said local jukeboxes, wherein the local 
jukeboxes download desired information automatically 
during a broadcast from the central storage location; 
and 

a scheduler for coordinating transmission from said cen- 
tral storage location to said local jukeboxes. 

2. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said menuing 
system includes a statistical replacement algorithm for 
retrieving additional portions of a menu based upon local 
accesses to said local jukebox. 

3. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said songs are 
placed on said local jukebox based upon user inquiries about 
availability. 

4. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein the local juke- 
boxes initiate communication with the central storage loca- 
tion and said music is retrieved by said local jukeboxes 
automatically based upon actual user preferences at a juke- 
box location. 

5. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said scheduler 
arranges the broadcast of songs simultaneously to a plurality 
of jukeboxes. 

6. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said scheduler 
delays transmission of music within a requested time frame 
to improve transmission times and minimize costs. 

7. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said transmission 
occurs automatically for non-interactive updates. 

8. A music distribution system for local digital electronic 
jukeboxes as claimed in claim 1, wherein said local jukebox 
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includes an advanced payment system to allow automatic 
access to said central storage system. 

9. A method for optimally transmitting music selections in 
a music distribution system comprising: 

maintaining statistics in a digital electronic jukebox, 5 

regarding a number of times a node in a menu hierarchy 

is reviewed by a user; 
using said statistics to indicate when a node has been 

reviewed a predetermined number of times; 
sending a request automatically for updated music from 10 

said jukebox to a central storage location, based on said 

statistics determined in said jukebox; 
receiving requested music within a time period specified 

in the request at said jukebox; 15 
said receiving step further including transmitting music 

from said central storage location to a plurality of 

jukeboxes simultaneously; and 
storing a portion of said menu hierarchy at said jukebox. 

10. A method for optimally transmitting music selections 20 
in a music distribution system as claimed in claim 9, wherein 
said menu hierarchy includes levels for music types, 
subtypes, albums, and songs. 

11. A method for optimally transmitting music selections 

in a music distribution system as claimed in claim 9, wherein 25 
said statistics represent actual user preferences at said juke- 
box location. 

12. A method for optimally transmitting music selections 
in a music distribution system as claimed in claim 9, wherein 
said transmitting is coordinated by delaying transmission 3Q 
times of a portion of the requested music within a delay time 
period defined in the request and according to a schedule to 
increase transmission efficiency and minimize costs. 

13. A music distribution system comprising: 

a central storage location including available songs, 35 
graphics and titles; 

a plurality of local computer jukeboxes separate from the 
central storage location; and 

at least one regional storage location separate from and 
communicating with the central storage location and 40 
the plurality of local computer jukeboxes, the at least 
one regional storage location storing a portion of the 
available songs and transferring available songs to the 
computer jukeboxes. 

14. The music distribution system of claim 13, further 45 
comprising: 

a first communications system between said central stor- 
age location and said at least one regional storage 
location; and 

a second communications system between said at least 50 
one regional storage location and each of said plurality 
of computer jukeboxes. 

15. The music distribution system of claim 14, wherein 
said first communications system includes one of a satellite 
transmission system, a telephone line, and a mailed diskette. 55 

16. The music distribution system of claim 14, wherein 
said second communications system includes one of a 
satellite transmission system, a telephone line, and a mailed 
diskette. 

17. The music distribution system of claim 14, wherein <jq 
said at least one regional storage location includes a master 
jukebox. 

18. A computer jukebox comprising: 

reception means for receiving songs from a central stor- 
age location; 65 
a memory for storing songs; 
playing means for playing stored songs; 
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an interface for output ting signals to control a compact 
disk changer to select and play a desired song. 

19. The computer jukebox of claim 18, further compris- 
ing: 

user selection means for selecting a song stored in one of 

said memory and on a compact disk in an attached 

compact disk changer; and 
means for outputting control signals to said compact disk 

changer through said interface to execute a selected 

song on a compact disk. 

20. The music distribution system of claim 1, further 
including: 

a data structure that relates similar songs, wherein the 
similar songs have a high probability of being preferred 
by users of a particular location. 

21. The music distribution system of claim 20, wherein 
the probability is defined by a local jukebox. 

22. The music distribution system of claim 20, wherein 
the probability is defined by a central storage system. 

23. The music distribution system of claim 2, wherein the 
local accesses to the local jukebox define a mix of music 
categories in which a percentage of songs for a given 
category is determined by user preferences. 

24. Trie music distribution system of claim 1, wherein the 
scheduler arranges the broadcast of songs automatically 
based on at least one of: user preferences at a jukebox 
location, anticipated use of similar songs which are available 
on the local jukebox, local music menu profiles and songs 
automatically transmitted from the central storage location 
to the local jukebox without a request. 

25. The music distribution system of claim 4, wherein the 
music is retrieved in advance of an automatic update based 
on an anticipated use of similar songs which are locally 
accessed songs, local music menu profiles and songs auto- 
matically transmitted from the central storage location to the 
local jukebox without a request. 

26. The music distribution system of claim 1, wherein the 
scheduler accumulates requests for each different song 
within a time period defined in the request, and wherein one 
broadcast is performed for the combination of the accumu- 
lated requests. 

27. The method for optimally transmitting music selec- 
tions of claim 9, further comprising: 

broadcasting a list of new available songs from a central 

storage location to a plurality of local jukeboxes; 
downloading said list into a local jukebox; 
downloading requested songs automatically during the 

broadcasting from the central storage location into the 

local jukebox; 
loading credits through payments in said local jukebox; 
decreasing a number of credits corresponding to a number 

of downloaded songs. 

28. The method for optimally transmitting music selec- 
tions of claim 9, wherein the music is retrieved from a 
hierarchy of classes of music, wherein the hierarchy is stored 
in its entirety in the central storage location. 

29. The method for optimally transmitting music selec- 
tions of claim 9, further including: 

deferring transmission of music based on local user needs; 
and 

transmitting music requested based on local user needs 
from said central storage location simultaneously to 
multiple jukeboxes, when requested delivery times 
overlap. 

* * * * * 
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